Before allowing entities to access a network and its associated resources, the general mechanism is to authenticate the entity (a device and/or user) and then allow authorization based on the identity. The most common access control is binary, i.e., it either allows access or denies access based on membership in a group.
Extending access control, especially to the wireless domain, requires the use of a more finely grained authorization. For example, one might want to allow access to the network and its resources for internal employees and allow Internet access for guests. Further access might be allowed based on the entity's membership in identity federations, e.g., inter-college access to researchers, inter-organization access based on collaboration on certain projects, and other similar groups and roles.
Typically, the authentication is based on a three-party model, where the three parties are; (a) the supplicant, which requires access; (b) the authenticator, which grants access; and (c) the authentication server (e.g., a AAA server), which gives permission. The supplicant has an identity and some credentials to prove that it (or its user) is who it claims to be. Examples of credentials are passwords, one-time tokens, digital certificates, and phone numbers (calling/called).
The supplicant connects to the network through an authenticator's port that is access controlled. The port is important because it acts as the choke point for the supplicant's access to the network resources. That is, access to the network can be controlled at a single point. The supplicant is called a peer in the RFCs (Request for Comments) and drafts promulgated by the IETF (Internet Engineering Task Force).
In the wireless domain, the most common supplicant is the STA (Station), e.g., a laptop or PDA, and the authenticator is the access point (AP). The STA to AP cardinality is 1:1; that is, one STA can, at one time, connect to the network through only one AP. This restriction fits well with concept of an access-controlled port in the EAP/802.1x protocol. The authenticator itself does not know whether an entity can be allowed access; that is the function of the authentication server. In the IETF world, the authenticator is often referred to as the network access server (NAS) or Remote Address Dial-In User Service (RADIUS) client. In some cases, the authenticator and the authentication server roles can be performed by one device, such as the 802.11 AP.
In a typical scenario, the supplicant initiates an access request and the authenticator starts an EAP message exchange. (In the stricter sense of the standards, such as 802.1x, the supplicant does not necessarily always initiate the access request, the authenticator can initiate an authentication request when it senses a disabled-to-enabled state transition of a port.) At some point, the authenticator communicates with the authenticator server, which decides on an authentication protocol to propose to the supplicant. If the supplicant agrees to the protocol, the authentication server will attempt an authentication according to the protocol against a statically configured credential store and either succeed with the authentication or wait for a timeout to occur. If the authentication succeeds, the authenticator allows network access to the supplicant through the port. The authenticator also keeps a security context with the supplicant-port pair. This context might trigger an event such as a timeout, if the authentication is only for a period of time (e.g., billed access in public WLAN). With respect to the foregoing paragraphs, see Krishna Sankar, Andrew Balinsky, Darrin Miller. Sri Sundaralingam, EAP Authentication Protocols for WLANs (Cisco Press; Feb. 18, 2005).
EAP is a user authentication protocol defined by IETF RFC 3748. Although EAP is not limited to wireless LANs (WLANs) and can be used for wired LAN authentication, it is most often used in WLANs. EAP is an authentication framework, not a specific authentication mechanism. EAP provides some common functions and a means for negotiation of a desired authentication mechanism. Such mechanisms are called EAP methods and they currently number about forty. EAP methods defined in IETF RFCs include EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, and EAP-AKA, in addition to a number of vendor specific methods such as EAP-MSCHAP. Common methods capable of operating in wireless networks include EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP and EAP-TTLS. The requirements for EAP methods used in WLAN authentication are described in RFC 4017.